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1. Introduction 


This memo lays out a conceptual framework and rules of thumb to 
assist working groups dealing with IPR issues. The goal is to 
achieve a balance between the needs of IPR claimants and the 
implementers of IETF standards which is appropriate to current times. 
As part of trying to distill out principles for dealing with IPR in 
IETF working groups, it provides case studies of working group IPR 
treatment. In other words, it documents the running code of the IETF 
process. 


This memo does not describe IPR procedures for document authors or 
IPR claimants. Those are covered in two other memos, on submission 
rights [5] and IPR in the IETF [6]. Rather, this memo is for working 
groups that are trying to decide what to do about technology 
contributions which have associated IPR claims. 


2. The Problem 


Traditionally the IETF has tried to avoid technologies which were 
"protected" through IPR claims. However, compromises have been made 
since before the IETF was born. The "common knowledge" of the IETF, 
that IPR-impacted technology was anathema, has never recognized that 
the Internet has run on IPR-impacted technologies from the beginning. 
Nowadays the majority of the useful technologies brought to the IETF 
have some sort of IPR claim associated with them. 


It will always be better for the Internet to develop standards based 
on technology which can be used without concern about selective or 
costly licensing. However, increasingly, choosing a technology which 
is not impacted by IPR over an alternative that is may produce a 
weaker Internet. Sometimes there simply isn’t any technology in an 
area that is not IPR-impacted. It is not always the wrong decision 
to select IPR-impacted technology, if the choice is made knowingly, 
after considering the alternatives and taking the IPR issues into 
account. 


The IETF is not a membership organization. Other standards-making 
bodies may have membership agreements that member organizations must 
sign and adhere to in order to participate. Membership agreements 
may include strict procedures for dealing with IPR, or perhaps a 


Brim Informational [Page 2] 


RFC 3669 WG IPR Guidelines February 2004 


requirement that technology must be licensed royalty-free. This is 
currently not possible in the IETF. 


Even if the IETF had membership agreements, they would be difficult 
to formulate in a way that covered IPR issues, because the IETF’s 
work includes technology from other sources and because the IETF 
collaborates with organizations that work with different approaches 
to intellectual property. The IETF can encounter four different IPR 
situations, at almost any time during the life of a document: 


o A document submitter notes their (or their represented 
organization’s) IPR claim regarding the contents of the document. 


o A non-submitter IETF participant claims that the contents of a 
document are covered by their (or their represented 
organization’s) own IPR. 


o An IETF participant notes IPR that is claimed by an individual or 
organization with which neither an author of the document, nor the 
participant noting the IPR, have an affiliation. 


o An individual or organization that does not participate in the 
IETF, but that monitors its activities, discovers that a document 
intersects that individual’s or organization’s established or 
pending intellectual property claims. It may come forward right 
away, or wait and let the IETF work progress. 


In working group activities, the IETF does not have detailed rules 
for each situation. Working groups have essentially only one rule 
they can invoke -- about individuals not participating in activities 
related to a technology if they do not disclose known IPR. Beyond 
that a working group can only make recommendations and requests. 


Since every case is unique, and there are close to no general rules, 
working groups need a great deal of freedom in dealing with IPR 


issues. However, some amount of consistency is important so that 
both contributors and users of eventual standards can know what to 
expect. 


3. The Approach 


The goal of this memo is not to make rules. The goal is to give 
working groups as much information as possible to make informed 
decisions, and then step out of the way. The other IPR working group 
memos [5][6] lay out what needs to be done once a particular piece of 
technology is selected as a working group draft. However, this 
doesn’t help when a working group is trying to decide whether or not 
to select a technology in the first place. This third memo is 
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written to help in making that decision. We want to builda 
conceptual framework, a new set of "common knowledge", to make it 
easier for working groups to deal with intellectual property issues. 


To do so, we first present "case studies" in Section 4 -- real events 
that have happened in recent years, and how different working groups 
dealt with them -- plus notes on possible lessons to be learned. In 


Section 5, we expand on these lessons and try to extract general 
principles. 


4. Case Studies 


The best way to know what works in dealing with IPR is to look at 
past attempts to do so. The following are selected as cases from 
which general lessons might be extracted. Other lessons might be 
extracted from other cases, but the cases below cover the important 
ones. 


4.1. PPP CCP and ECP 


The PPP Working Group adopted technology for PPP’s Connection Control 
Protocol and Encryption Control Protocol about which an IPR 
disclosure had been received. They indicated to the IESG that they 
believed the patented technology was the best approach, and was 
better than no standards at all. 


At that time, under the policies documented in RFC 1602 [1] (the 
precursor to RFC 2026), progress on any standard was to stop at the 
Proposed Standard phase until specific assurances about licensing 
terms could be obtained from all IPR claimants. However, as 
described in RFC 1915 [3], in the case of PPP ECP and CCP, the IPR 
claimant balked at the requirement for specific assurances. 


In the end, with support from the working group, the variance 
procedure described in RFC 1871 [2] was followed to grant an 
exception to the RFC 1602 requirements. If it had not been granted, 
the ECP and CCP standards could have been blocked permanently. 


Lessons: 


o IPR claimants, even when their intentions are good, may strongly 
resist being forced to make specific public statements about 
licensing terms. If explicit statements of licensing terms are 
required, then the publicly stated terms will probably be 
"worst-case", which would provide little useful information. 
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4.2. IPS WG (IP Storage) 


The IPS (IP Storage) Working Group evaluated technology developed 
outside of the working group, "Secure remote password" (SRP, RFC 2945 
[7]). At the time, there was one known IPR claim, and the proposed 
licensing terms were apparently reasonable. SRP had become a 
proposed standard without going through any working group, so IETF 
participants may have been less likely to notice it in order to make 
statements about IPR. In any case, two more possible IPR claims were 
uncovered after the IPS working group had already decided to make SRP 
required. One of the possible IPR claimants did not make a strong 
IPR claim itself, and did not want to take the time to determine 
whether it actually had a claim, though it acknowledged it might have 
a claim. In both cases it was difficult to obtain concrete 
information on possible licensing terms, even though words like 
"reasonable" and "non-discriminatory" were used in the IPR 
statements. Rumors of what they might be like did not sound good. 
The working group participants took the claims, potential and 
otherwise, very seriously, and decided not to use SRP after all, even 
though they had already chosen it based on other criteria. 


Lessons: 
o IPR claims may appear at any time in the standards process. 


o Take impreciseness seriously. Attempt to get clarification on 
both IPR claims and licensing terms. 


4.3. PEM and PKI issues 


The PEM (Privacy-Enhanced Mail) Working Group wanted to use public 
key technology. In the mid-90s, the basic principles of public key 
infrastructure had been patented for years. The patent holder had 
shown a tendency to actively enforce its rights, and to prefer 
software sales to licensing. This was seen as a significant 
potential issue, one which could possibly interfere with the easy 
deployment of Internet technology. However, there was no alternative 
technology that came close to its capabilities. Adopting an 
alternative would have damaged the standard’s usefulness even more 
than adopting a technology with IPR claims. The case was so 
compelling that the working group participants decided to move 
forward on standardizing it and even requiring it. 


One factor which was noted was that the patents were mature, and 
would expire within a few years. That meant that although the 
patents might be significant to start with, they would not be in the 
long run. This lowered the perceived risk of using the IPR-impacted 
technology. 
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Lessons: 


o IPR is just one issue in deciding whether to adopt a technology. 


o IPR is not an all-or-nothing issue. There are different types and 
levels of IPR protection. 


o The IPR’s lifecycle phase can be a consideration. 
4.4. VRRP (Virtual Router Redundancy Protocol) 


The working group was standardizing VRRP based on a protocol 
developed outside the IETF. The IPR claimant supported that protocol 
and stated that it would license its IPR for that protocol if it 
became the standard, but not for the similar protocol the working 
group was developing. The working group participants decided to go 
ahead and standardize the protocol developed in the working group 
anyway. The IPR claimant has only claimed its patent when someone 
else claimed a patent against it. There is no evidence that the 
working group participants actually thought about the implications of 
the IPR claim when they went ahead with their choice of protocol. 


Lessons: 


o IPR claims should never be disregarded without good cause. Due 
diligence should be done to understand the consequences of each 
claim. 


Mew Dee Secure Shell (SecSH) 


This is primarily an unfinished trademark issue, not a patent issue, 
since the patent issue has been worked out outside of the IETF. The 
holder of a trademark wants the IETF to stop using "SSH" in the names 
and bodies of its proposed standards. The working group participants 
have thought through the details of the claims, and possible 
implications and risks, and decided to go ahead and continue using 
the names as they are now. 


Lessons: 
o Working group participants can evaluate IPR claims not only for 
their possible validity, but also for the risk of misjudging that 


validity. The impact of honoring the IPR claim may be major or 
minor. 


Brim Informational [Page 6] 


RFC 3669 WG IPR Guidelines February 2004 


4.6. IDN (Internationalized Domain Name) 


The IDN Working Group dealt with a number of IPR claims. Several 
were made which did not overlap with the technology -- the IPR 
claimants said the patents were being announced just in case the 
working group decided to go that way. In one case, even though a 
patent was announced as purely defensive, many working group 
participants investigated the claims themselves. They concluded that 
it did not overlap. 


In one case, an IPR claimant asserted that the working group’s 
documents, and in fact the IETF as a whole, were infringing on its 
rights. Individual working group participants consulted with their 
legal advisers, concluded that the claims would not overlap the 
working group’s developing technology, and decided that they need not 
be concerned about the claims. This was reflected in the direction 
the group as a whole decided to take. 


In another case, patent claims were asserted that appeared to be 
derived from working group discussion, rather than vice versa (or 
independent discovery). The claimants were known to be following the 
working group’s work when the ideas were proposed, and their patent 
filing was considerably subsequent to that time. 


In 2000 the IDN Working Group discovered a patent that some 
participants thought might apply to one of their main drafts. If it 
did, it could affect their work profoundly -- to the extent that some 
suggested that if they could not work out reasonable licensing terms 
with the IPR claimant they might just disband. As a group and 
individually, participants corresponded with the IPR claimant in 
order to get an explicit statement of licensing terms, preferably 
royalty-free. By doing so they gained a better understanding of just 
which working group activities were seen as infringing on the patent, 
and at least some understanding of the IPR claimant’s intentions and 
philosophy. Since the patent holder seemed to have an interest in 
using the patent for profit, the group discussed the issues on its 
mailing list. They overtly talked about how they could change their 
proposed technology to avoid having to contest the patent, and the 
extent to which the patent might be countered by claims of prior art. 
Meanwhile, individually they were talking to their legal advisors. 
Gradually, a collective opinion formed that the working group 
documents did not infringe on the patent. Since then, the patent has 
been ignored. However, they are keeping a watchful eye out for 
continuation patents which might have already been submitted. 
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Lessons: 


o It’s sometimes beneficial to push IPR claimants to find out what 
they think their claims cover and what their licensing terms are. 


o Possibilities of prior art should be considered. 


o It’s all right, and sometimes beneficial, to discuss IPR claims 
and gather information about possible prior art on the group list. 
The results of such discussion can be considered when deciding 
whether to develop a technology (but remember that neither the 
IETF nor any working group takes a stand on such claims as a body, 
and the group is not the best place to get legal advice). 


General Principles 


Given the case studies above, there are a few principles that working 
groups can start with in dealing with IPR. Every working group needs 
to develop and follow its own consensus, and actual treatments will 
vary as much as they have in the past. However, every working group 
also needs to take IPR seriously, and consider the needs of the 
Internet community and the public at large, including possible future 
implementers and users who will not have participated in the working 
group process when the standardization is taking place. 


Types of IPR 


A primer on the different types of IPR would be large, unreliable, 
and redundant with other Working Group documents [4][5][6]. For 
informal exploration, see those documents and other relevant sources 
on the web. Readers with more serious concerns should consult their 
legal advisors. In the United States, briefly: 


O Trademarks indicate the sources of goods. Service marks indicate 
the sources of services. They protect the use of particular marks 
or similar marks. 


o Copyrights protect the expressions of ideas (not the ideas 
themselves), in almost any form, and allow "fair use". Copyrights 
expire but they can be renewed. 


o Patents protect "inventions". They expire (utility patents expire 
after 20 years), but follow-on patents can cover similar 
technologies and can have nearly the same implications for use in 
the Internet as the original patents. 
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5.2. When to Think About IPR 


This memo does not describe IPR procedures for document authors or 
IPR claimants. Rather, this memo is for working group participants 
who are trying to decide what to do about IPR claims related to their 
work. A working group as a whole needs to think about IPR issues: 


o when examining a technology, and deciding whether to initiate work 
on it. 


o when deciding whether to adopt a draft as a working group 
document. 


o when choosing between two or more working group drafts that use 
different technologies. 


o when deciding whether to depend on a technology developed outside 
the working group. 


o when comparing different kinds of IPR protection. 


At each of these times, the working group is strongly encouraged to 
solicit disclosure of IPR claims and licensing terms. A working 
group’s job will be a lot easier if IPR details are discovered early, 
but it should realize that IPR claims may appear at any time. 
Working groups should anticipate that an IPR claimant might choose 
not to participate in the IETF, but instead to monitor froma 
distance while the relevant technology is being discussed and 
evaluated. A working group’s knowledge of IPR claims may therefore 
depend upon when a claimant steps forward during the course of a 
working group’s deliberations. 


5.3. IPR as a Technology Evaluation Factor 


How do you weigh IPR claims against other issues when deciding 
whether to adopt a technology? 


The ultimate goal of the IETF is to promote the overall health, 
robustness, flexibility, and utility of the Internet infrastructure. 
We base architectural decisions on our long-term extrapolations of 
requirements by thinking in these terms. When considering a 
particular technology, we compare it with other technologies not just 
for its elegance of design in and of itself, but also for how it fits 
in the bigger picture. This is done at multiple levels. It is 
examined for how it fits into the overall design of the working 
group’s output, how it fits into the particular Internet 
infrastructure area, how it fits with work going on in other areas, 
and how it fits in the long view of the Internet architecture. 
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Similarly, when evaluating a technology, working group participants 
consider IPR claims on it (including possible copyright issues with 
text describing it). The issue is not whether a particular piece of 
technology is IPR-impacted -- we use IPR-impacted technology every 
minute. The question is how much the IPR protection will limit the 
technology’s usefulness in building a robust, highly useful Internet. 
Thus, the only significant questions are: is the IPR claim relevant, 
and what are the terms under which the technology can be used? When 
technology is free from IPR protection the answer is easy. When it 
is IPR-impacted, some licensing terms make the IPR issues 
insignificant compared to the engineering issues. Other terms can 
make a technology unusable even if it is perfect otherwise. 


The problem with IPR as a technology evaluation factor is that it is 
unlikely that a working group, as an entity, can ever claim to have 
reached consensus on most IPR issues. The IETF as a whole, anda 
working group as a whole, takes no stance on the validity of any IPR 
claim. It would be inappropriate for a working group chair to 
declare that consensus had been reached that, for example, a 
company’s patent was invalid. Individual participants will need to 
use whatever legal advice resources they have access to in order to 
form their own individual opinions. Discussions about the validity 
of IPR may take place under the auspices of the working group, in 
particular about relative risks of technology choices. Individual 
participants may take these discussions into account. The working 
group as a body may not take a stance on validity, but it may make 
choices based on perceived risk. 


5.4. Patents versus Pending Patents Applied For 


The IETF does not (cannot) expect IPR claimants to tell a working 
group specifically how they think a particular patent applies. Ifa 
patent has already been granted, the IETF can reasonably expect 
disclosure of the patent number and possibly the relevant IETF 
document sections, which will allow working group participants to 
explore details of the claims. If a patent has not yet been granted 
(or if knowledge of the patent is restricted, e.g., for security 
reasons), significantly less information is available. In most 
countries patent applications are published 18 months after they are 
filed, but in the USA that can be avoided if the applicant does not 
also file outside the USA. In some countries applications are a 
matter of public record, but details of pending claims can be 
modified at any time by the claim submitter before the patent is 
granted. It is not known before then what rights will actually be 
granted. Finally, rights can be contested in court, and nothing is 
final until the courts decide -- perhaps not even then. All the IETF 


Brim Informational [Page 10] 


RFC 3669 WG IPR Guidelines February 2004 


can expect regarding a pending patent is disclosure that it exists, 
the related IETF documents, and possibly the relevant IETF document 
sections and some statement about licensing terms. 


5.5. Applicability: It’s Hard to Prove a Negative 


Working group participants must make their own decisions about what 
level of confidence they need as to whether IPR is applicable. 
However, perfect knowledge is not a worthwhile goal. 


In general, a working group should strive to find out about all IPR 
claims related to technologies it is considering, and at least the 
general facts about licensing terms for each case -- for example 
whether the terms will be royalty-free, or perhaps "reasonable and 
non-discriminatory". Working group participants should also 
investigate possibilities of prior art which would counter the IPR 
claims. However, even if the working group participants do 
exhaustive searches, both externally and internally to their 
employers, it is impossible to prove that a particular technology is 
not covered by a particular IPR claim, let alone prove that it is not 
covered by any IPR claim. Anything a working group adopts may, in 
the future, turn out to be IPR-impacted, although the IPR claim may 
not be discovered until years later. Claims are open to 
interpretation even after rights are granted. Drafts can be very 
fluid, even up to the time of last call, and IPR issues may 
unknowingly be taken on at any time. Absolute certainty about IPR 
claims is rare. 


However, the level of confidence needed to consider IPR when 
evaluating a technology is often not hard to get to. There are cases 
where risk is high (e.g., where licensing terms may be onerous) and 
thus a high level of confidence about applicability is needed, but 
history shows that most of the time "rough" confidence is good 
enough. 


In all cases, licensing terms are a more significant consideration 
than the validity of the IPR claims. Licensing terms often do not 
limit the usefulness of the technology. It is difficult to be sure 
about the validity of IPR claims. If the licensing terms can be 
determined to be reasonable, then the IPR claims become much less 
important. 
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5.6. Licensing Terms 


Licensing terms vary across a range from no license required at all 
to prohibitive. In general, working groups show a preference for 
technologies with IPR considerations in approximately the following 
order. This list does not constitute a rule, and every working group 
needs to take its own circumstances into account. 


o License not required. 
o IPR licensed with no restrictions. 


o IPR licensed with no material restrictions, e.g., no trademark 
license required. 


o IPR licensed for a particular field of use but with no other 
material restrictions, e.g., licensed solely for implementations 
complying with a standard. 


o IPR licensed under royalty-free terms and reasonable and 
non-discriminatory restrictions. 


o IPR licensed under reasonable and non-discriminatory restrictions. 
This may include payment of a royalty. 


o IPR which is otherwise licensable. 


o IPR which is not licensable, i.e., which is only available as an 
implementation. 


o IPR which is not available under any conditions. 


Many IPR claimants do not like to publish specific terms under which 
they will issue licenses. They may use standard terms for many 
licensees, but they prefer to negotiate terms for some. Therefore, 
do not expect any IPR disclosure statement to lay out detailed 
blanket terms for licensing. 


If an IPR disclosure statement lists only vague terms, that doesn’t 
mean the terms that will be offered in individual licenses will be 
any worse than those offered if an IPR disclosure makes very specific 
statements. Obviously, if an IPR claimant refuses to suggest any 
terms at all, the working group is going to have trouble evaluating 
the future utility of the technology. 


There is a class of restriction which involves "reciprocity", in 


which intellectual property may be licensed if the licensee is 
willing to license its intellectual property in return. The 
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specificity of such agreements can vary, and the same or similar 
terms may be required. Another potential licensing restriction is 
defensive suspension, where a licensor may revoke or suspend the 
license if the licensee asserts a patent claim against the licensor. 
For interpretation of any particular reciprocity or related issue, 
consult your legal adviser. 


Words such as "reasonable", "fair", and "non-discriminatory" have no 
objective legal or financial definition. The actual licensing terms 
can vary tremendously. Also, IPR claimants have occasionally 
asserted that there were already sufficient licenses for a particular 
technology to meet "reasonable" multisource and competitiveness 
requirements and, hence, that refusing to grant any licenses to new 
applicants was both fair and non-discriminatory. The best way to 
find out what an IPR claimant really means by those terms is to ask, 
explicitly. It also helps to gather knowledge about licenses 
actually issued, for that technology or for others, and about other 
experiences with the IPR claimant. 


Despite the fact that IPR claimants often don’t like to publish 
explicit terms, there are levels of vagueness, and individuals and 
even working groups can sometimes successfully push an IPR claimant 
toward less vagueness. Many employers of IETF participants know that 
the IETF prefers explicit terms, and do feel pressure to produce 
them. 


If working group participants are dissatisfied with the confidence 
level they can obtain directly about licensing terms for a particular 


technology, they can possibly extrapolate from history. In order for 
licensed technology to become a draft standard, at least two 
independent licenses need to have been issued. If the IPR claimant 


for the technology the working group is considering has licensed 
other technology in the past, there is a record of the sorts of terms 
they are willing to grant, at least in those specific cases. This 
sort of thing is weak but everything counts, and it may be of some 
help. 


In many jurisdictions that issue patents, inventors are required to 
file patent applications within 12 months of public disclosure or use 
of a novel method or process. Since many of these jurisdictions also 
provide for publication of pending patent applications 18 months 
after a patent application is filed, the ability to determine whether 
or not claims have been made at all relating to a particular 
technology increases 30 months (12 + 18) after the public disclosure 
or use of that technology. 
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5.7. Third-Party Disclosure of IPR Claims 


It is good to notify the IETF of relevant IPR claims even when they 
are not one’s own, and [6] says to do so "as soon as possible". 
However, anyone considering such a disclosure should do some 
preliminary exploration with the affected working group(s) beforehand 
(see Section 5.7.1). Third-party disclosure is a potential denial of 
service threat to the working group, and therefore it is good form to 
proceed slowly at first. 


Working group participants should be aware that third-party 
disclosure can be used, knowingly or unknowingly, to defocus and 
distract the working group and hinder its progress. They should 
evaluate third-party disclosures accordingly. Working group chairs 
should be willing and able to discipline those they think are using 
the third-party disclosure system inappropriately. Those who think 
they are being unfairly blocked may take the matter up with the Area 
Directors and/or the IESG. 


All of the criteria for evaluating IPR claims discussed in the 
sections above apply in the case of third-party disclosures as well, 
to the extent they can be practiced. 


5.7.1. Third-Party Disclosure Advice 


This subsection provides advice to those considering making 
third-party disclosures. While not required, the actions described 
here are encouraged to aid working groups in dealing with the 
possible implications of third-party disclosures. In evaluating what 
(if anything) to do in response to a third-party disclosure, a 
working group may consider the extent to which the discloser has 
followed this advice (for example, in considering whether a 
disclosure is intended primarily to defocus and distract the working 
group). 


In general a potential discloser should exchange mail with the 
working group chair(s) first, to open the way for discussion. Also, 
if the potential discloser is not sure if the IPR claim applies, this 
is the time to reach some kind of agreement with the working group 
chair(s) before saying anything publicly. After discussion with the 
working group chair(s), the potential discloser should bring the 
issue to the attention of the working group, and to the attention of 
the IPR claimant if doing so is not too difficult. Such discussion 
should help the potential discloser to become more sure, one way or 
the other. If the potential discloser is sure the discovered IPR 
claim applies, and the IPR claimant does not submit a first-party 
disclosure itself, then the potential discloser is encouraged to 
submit a third-party disclosure. 
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8. 


8. 


Intellectual property often applies to more than one working group. 
A person thinking of making a third-party disclosure should consider 
what other working groups might be affected, and communicate with 
them in the same manner. 


Don’t bring up IPR issues that are unrelated to the areas where the 
working group is focusing at that time. Don’t bring IPR claims to 
the working group’s attention just in case they might be relevant in 
a few months, but only if they have implications for current work. 
Messages to the working group list should be substantive, anda 
single message should focus on a specific issue. They can reference 
multiple claims or patents related to that issue. 


Security Considerations 


This memo relates to IETF process, not any particular technology. 
There are security considerations when adopting any technology, 
whether IPR claims are asserted against it or not. A working group 
should take those security considerations into account as one part of 
evaluating the technology, just as IPR is one part, but they are not 
issues of security with IPR procedures. 
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10. Full Copyright Statement 


Copyright (C) The Internet Society (2004). This document is subject 
to the rights, licenses and restrictions contained in BCP 78 and 
except as set forth therein, the authors retain all their rights. 


This document and the information contained herein are provided on an 
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 

REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
Intellectual Property Rights or other rights that might be claimed 
to pertain to the implementation or use of the technology 
described in this document or the extent to which any license 
under such rights might or might not be available; nor does it 
represent that it has made any independent effort to identify any 
such rights. Information on the procedures with respect to 

rights in RFC documents can be found in BCP 78 and BCP 79. 


Copies of IPR disclosures made to the IETF Secretariat and any 
assurances of licenses to be made available, or the result of an 
attempt made to obtain a general license or permission for the use 
of such proprietary rights by implementers or users of this 
specification can be obtained from the IETF on-line IPR repository 
at http://www.ietf.org/ipr. 


The IETF invites any interested party to bring to its attention 
any copyrights, patents or patent applications, or other 
proprietary rights that may cover technology that may be required 
to implement this standard. Please address the information to the 
IETF at ietf-ipr@ietf.org. 
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